# Pepvoid Gaming Edition — implementation plan Status: software prototype implemented; ISO and hardware qualification are tracked in [Gaming Edition](gaming-edition.md). The original phased plan is retained below. The Sysadmin handbook is a separate completed deliverable. Research date: 2026-10-20. Repository availability, driver support and upstream versions must be rechecked when implementing and recording a release manifest. ## Product target Build a complete gaming desktop with working graphics, 32-bit compatibility, launchers, controllers and useful diagnostics immediately after installation. Use Bazzite, Nobara and CachyOS as feature and measurement references. Performance claims require results on identical hardware; a package list cannot establish that this edition is faster than another distribution. Recommended first target: **x86_64 glibc, KDE Plasma Wayland**, using the existing validated Pepvoid desktop and SDDM branding. Desktop choice remains a product preference to confirm; do not change the preset's current XFCE base silently. Keep other existing desktop editions unchanged. A separately tested gaming session/handheld flavor can follow the desktop edition. Release priorities, in order: 1. Correct GPU selection and functioning 64/32-bit graphics/audio paths. 2. Steam, Proton and non-Steam launchers with clear runner management. 3. Stable input, audio, displays, suspend/resume and game capture. 4. Reversible, measured optimizations and useful diagnostics. 5. A polished English Gaming Center, onboarding and offline troubleshooting. ## Reference features and what to adopt | Reference | Verified emphasis | Pepvoid implementation decision | | --- | --- | --- | | Bazzite | Gaming desktop/game-mode options, graphics and controller integration, HDR/VRR | Prioritize hardware integration; validate desktop first, then a separate game-mode session. Do not claim atomic updates/rollback from an ordinary XBPS installation. | | Nobara | Gaming/creator focus and kernel/graphics tuning | Evaluate changes individually; maintain a standard-kernel fallback and optional creator tools. | | CachyOS | Gaming runtime and launcher groups, Proton integration and performance guidance | Separate required libraries from optional applications; test runners and settings per game. Its Arch packages cannot be installed as Void packages. | These references describe features, not a ranking of measured performance. See [Bazzite](https://bazzite.gg/), [Nobara](https://nobaraproject.org/) and the [CachyOS gaming guide](https://wiki.cachyos.org/configuration/gaming/). ## Existing repository audit The current `configs/presets/gaming.json` already selects XFCE, multilib/nonfree, Steam, Wine, GameMode, Vulkan and vkBasalt. It also pulls broad printing, multimedia and internet profiles. This is a starting point, not a validated complete gaming stack. Before adding features: - Resolve the case mismatch: the preset asks for `mangohud`, while the software profile and current upstream Void template use **`MangoHud`**. - Audit the assembled package plan, not just the preset: remove duplicate requests, confirm 32-bit providers and detect dependencies pulled by profiles. - Replace broad application groups with an explicit edition selection while keeping required desktop, network, accessibility and driver dependencies. - Verify repository activation precedes multilib/nonfree dependency resolution. - Audit inherited service links: no accidental SSH server, printer service or duplicate audio/power manager should be enabled by this edition. - Preserve other desktops' existing package/service behavior. Apply edition overlays and hooks only to the gaming preset. ## Package and delivery matrix Names below are requested package candidates or upstream application names, not a claim that every binary is currently available in official XBPS mirrors. Resolve exact names and dependency transactions during phase 1. A source template alone is not evidence that an installable binary exists for our target. | Layer | First-release selection | Delivery/validation requirement | | --- | --- | --- | | Desktop | Validated Plasma Wayland, SDDM, Xwayland, KDE portals, browser, file/archive manager | Reuse existing desktop behavior; check installer and installed-user integration. | | Steam | Native `steam`, required nonfree/multilib repositories | One primary Steam installation; client login/download happens as the user. | | Core graphics | `mesa-dri`, `vulkan-loader`, matching AMD/Intel Vulkan providers | Include matching `-32bit` runtime packages where required and available. | | Common 32-bit runtime | `libgcc-32bit`, `libstdc++-32bit`, `libdrm-32bit`, `libglvnd-32bit`, audio dependencies | Validate native 32-bit and Proton paths, not only a 64-bit Vulkan demo. | | NVIDIA | Appropriate supported driver family, matching 64/32-bit userspace and kernel integration | Detect supported GPU generation; do not force one proprietary branch onto every card. | | Launchers | Steam and Lutris; Heroic for Epic/GOG/Amazon | Prefer maintained native XBPS packages; otherwise evaluate a managed Flatpak or a signed Pepvoid package. | | Runners | Steam-managed Proton; Wine/Winetricks for applicable non-Steam games | GE-Proton is an optional per-game selection through a validated manager; no global forced experimental runner. | | Runner management | ProtonUp-Qt or equivalent maintained manager; UMU where required by launcher integration | Confirm package route and runit/elogind compatibility; verify downloads and update behavior. | | Monitoring | `MangoHud`, available 32-bit overlay components, optional GOverlay | Overlay is opt-in; supply an unobtrusive preset and frame-time logging instructions. | | On-demand performance | `gamemode`, matching library packages | Validate D-Bus activation, user authorization, state restoration and crash behavior. | | Per-game compositor | `gamescope`; matching mangoapp package if used | Nested operation first; NVIDIA/HDR/VRR coverage required before advertising support. | | Controllers | Steam Input plus applicable controller udev rules and Bluetooth support | Test real USB/Bluetooth devices; no blanket world-writable input permissions. | | Audio and capture | Existing PipeWire/WirePlumber setup, appropriate codecs and KDE screencast portal | Preserve working audio startup; test microphone, HDMI, Bluetooth and game/voice mixing. | | Basic diagnostics | Vulkan tools, GL renderer inspection, hardware inventory, GameMode self-test | Check exact package names and use unprivileged reports where possible. | The Void Steam notes explicitly require the relevant 32-bit graphics stack and matching NVIDIA libraries. Retain the existing PipeWire audio solution and test its compatibility rather than introducing a second competing sound server. See [Void Steam packaging notes](https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/steam/files/README.voidlinux). Upstream templates currently exist for [MangoHud](https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/MangoHud/template), [GameMode](https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/gamemode/template) and [Gamescope](https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/gamescope/template). Their versions and available binary builds must be checked again at implementation. ### Optional applications, installed on request - OBS Studio and a validated hardware encoder path for recording/streaming. - Discord or another voice client, with verified screen/audio sharing. - Moonlight/Sunshine for game streaming after supported delivery is established. - RetroArch and selected emulators; no bundled ROMs, commercial games or BIOS. - vkBasalt/ReShade-related post-processing, enabled per game. - Additional runner versions, launchers and mod tools when actually needed. Do not preload several complete copies of Steam/Wine or every emulator. Do not ship source SDKs, compiler collections, office suites, recovery tool collections, print servers or creator suites merely because a broad profile includes them. Do not remove a required library just because its name appears unrelated. ## Drivers and hardware paths Provide one usable base installer first, with post-install hardware selection. Split NVIDIA and AMD/Intel installation artifacts only if kernel/userspace packaging or Live validation makes a common image unreliable. For AMD and Intel: - Resolve the actual Vulkan ICD and renderer selected, including 32-bit. - Detect software rendering and fail the readiness check instead of silently reporting the system as ready. - Test VA-API and capture separately from 3D; driver names alone prove neither. For NVIDIA: - Match the kernel module and userspace versions, including multilib. - Test Wayland explicit-sync behavior, Xwayland games and Gamescope on supported hardware; document older GPUs separately. - Verify module rebuilds after kernel updates before declaring update success. - Test hybrid systems: internal display, offloaded game, external monitor and return to normal desktop power use after the game exits. Across vendors: validate refresh-rate persistence, multi-monitor behavior, VRR, HDR where actually supported, display hotplug and suspend/resume. Publish the hardware combinations tested. No universal HDR claim based only on Plasma's presence. No host-driver changes while building the ISO. ## Optimization policy ### First baseline: supported stock components Use Void's maintained kernel and graphics packages for the first reproducible baseline. Record kernel config, CPU microcode, firmware and Mesa/NVIDIA versions. Check Proton requirements and actual renderer before applying tuning. ### Candidates to validate | Candidate | Evaluation | Default policy | | --- | --- | --- | | GameMode | Frame times, clocks, permissions, process/crash cleanup | Enable a documented per-game launch path after validation; restore previous state. | | NT synchronization | Kernel `CONFIG_NTSYNC`, device availability/access and runner support | Use only when kernel and runner support it; no blanket environment-variable claim. | | Memory-map/file-descriptor limits | Confirm a real runtime requirement and appropriate PAM/user application | Scope to this edition, document values and test 32-bit as well as 64-bit. | | Zram/swap policy | Measure memory pressure, CPU cost and frame-time spikes at multiple RAM sizes | Keep one coordinated implementation; no universal swappiness recipe. | | CPU power/EPP policy | Compare desktop/laptop, AC/battery, temperatures and sustained load | Change on demand; no permanent maximum-frequency override. | | I/O scheduler/read-ahead | Storage-specific measurements on SATA/NVMe and HDD | Preserve kernel defaults unless there is repeatable evidence of a benefit. | | Alternative kernel/scheduler | Controlled A/B tests, NVIDIA compatibility, suspend and long sessions | Optional experimental track after the stock release; maintain rollback. | | Shader caches | Startup/stutter measurements, storage budget and cleanup | Use launcher/driver mechanisms; no unlimited cache growth or deletion on every login. | The kernel documents NT synchronization through `/dev/ntsync`; the kernel API alone does not prove that a particular Proton/Wine build uses it. Validate the whole path. See [kernel NT synchronization documentation](https://docs.kernel.org/userspace-api/ntsync.html). Use one authority for power/scheduling changes. Do not stack competing tuning daemons by default. Do not force CPU isolation, disable SMT, apply overclocks, disable security mitigations or inject generic graphics variables globally. For every retained tweak, record its scope, measured result and reversal path. GameMode is explicitly an on-demand mechanism; Gamescope is a compositor with hardware-dependent behavior. Neither is a universal FPS multiplier. See [GameMode](https://github.com/FeralInteractive/gamemode) and [Gamescope](https://github.com/ValveSoftware/gamescope). ## English Gaming Center and help Create an edition-local center rather than modifying the approved desktop UX. Suggested pages: - **Get started:** Steam/Lutris/Heroic, first-run network/download requirements. - **System readiness:** selected GPU/driver, Vulkan, 32-bit runtime, sound, controller detection and warnings with actionable repair information. - **Game tools:** overlay, performance logging, runner management and per-game profiles with their current state visible. - **Libraries:** choose additional storage, permissions and mount persistence; explain why sharing NTFS game libraries with Windows can be problematic. - **Troubleshooting:** black screen, missing Vulkan, no sound, wrong GPU, controller access, launcher logs and a privacy-conscious support report. - **Optional apps:** recording/streaming/emulation, explicit install actions. No automatic login to stores, downloads of user games or global account configuration. Diagnostics must never publish user data. Every optimization control needs an obvious reset action. Include offline English help and per-game Steam launch examples after validating their actual wrapper ordering. ## Boot, storage and update reliability - Validate the installed system independently of the Live ISO: graphics modules, multilib repos, user groups, services and permissions must survive installation. - Keep at least one known-working kernel and a reachable boot menu during kernel testing. Provide a documented recovery route for a broken graphics update. - Do not advertise atomic rollback unless the filesystem, boot integration and application data implications are implemented and tested. - Test ext4 as a straightforward baseline; consider optional Btrfs snapshots only with a complete recovery procedure, not an assumed installer capability. - Resolve restricted/proprietary application delivery and redistribution terms before bundling artifacts. Pin external build inputs and verify checksums. - Keep the build manifest and package/update provenance for each released ISO. ## Test matrix and release gates VirtualBox/VMware validate installer, menus and session startup. They do not qualify native gaming performance, HDR, VRR or physical GPU-driver behavior. | Dimension | Required coverage | | --- | --- | | GPU | At least one supported AMD, Intel and NVIDIA configuration; hybrid laptop before claiming hybrid support. | | APIs | Native OpenGL/Vulkan, 32-bit game/runtime, representative DX9/11/12 through supported Proton runners. | | Sessions | Wayland + Xwayland; optional fallback session only if packaged and tested. | | Input | Keyboard/mouse, USB and Bluetooth gamepad; reconnect and suspend/resume. | | Audio | Analog/USB/HDMI, microphone and voice-client mixing; Bluetooth where supported. | | Displays | High refresh, multi-monitor and hotplug; VRR/HDR on claimed supported combinations. | | Lifecycle | Fresh installation, first user, logout/login, reboot, kernel/driver update, game crash and power-state restoration. | | Storage | Secondary library, remount after reboot, correct ownership, low-space behavior. | | Features | Overlay, frame-time logging, capture portal and optional recording/streaming path. | Performance protocol: 1. Choose available benchmark scenes/titles and record exact build, driver, runner, resolution, preset, frame cap, VRR state and power settings. 2. Use the same physical machine, firmware settings and game build for Pepvoid and each comparison distro. Match configurable settings; record unavoidable stack differences and separately test each distro's recommended defaults. 3. Separate cold shader-cache runs from warmed runs. Repeat each warmed case at least three times; report median and spread, not the best single run. 4. Record average FPS, a clearly defined low-FPS percentile metric, frame-time percentiles/plots, stutter events, GPU/CPU temperatures and power if available. Use the same calculation for every result. 5. Include CPU-limited, GPU-limited and memory-pressure scenarios. Repeat any improvement close to ordinary run-to-run variation. 6. Reject a tweak that buys a small peak gain through crashes, worse frame-time tails, excessive heat or broken suspend. Publish both gains and regressions. Release gates: no unresolved package names; no silent software rendering on a supported test system; functional 32-bit path; successful representative games; repeatable baseline results; no recurring audio/input resets; tested driver/kernel update recovery. Anti-cheat, DRM and publisher decisions remain game-specific; do not promise every Windows title or native PC Game Pass compatibility. ## Implementation sequence 1. **Inventory and package proof:** validate current preset, exact XBPS package names, repo order, 32-bit dependencies and optional-app delivery. Produce an installable transaction and installed-size comparison before ISO work. 2. **Desktop prototype:** confirm desktop choice, implement edition-scoped package/service selection and branding; build one ISO and verify installation. 3. **Graphics and runtime qualification:** AMD/Intel/NVIDIA checks, Proton/Lutris runners, controllers, audio, user permissions and secondary libraries. 4. **Gaming Center and documentation:** ready-state checks, launchers, reports, optional apps and reversible settings. No optimizations without working basics. 5. **Measured optimization:** tune one variable at a time against the baseline; keep only reproducible improvements and retain a default reset path. 6. **Release candidate:** hardware matrix, long-session tests, update/recovery checks, documented limitations and reproducible comparison results. 7. **Later extensions:** a separately qualified Gamescope gaming session, handheld support and optional custom-kernel track when maintainable. Implementation started with phase 1. Hardware qualification and measured tuning remain release gates; this plan makes no claim of superiority.